Retailers use point of sale hardware and software systems (POS systems) to streamline sales operations and to allow them to process sales, handle payments, and store transactions for later retrieval. POS systems generally comprise a number of elements including point of sale terminals that are connected to a controlling server (the “back-office” servers) using an internal network connection. In a large retail environment, such as a supermarket, there may be a plurality of such POS terminals in communication with the back-office servers. It is noted that the back-office servers may be located locally (e.g. within the store) or remotely (in which case the POS terminals may be in communication with the back-office servers via a local communications network and a further communications network such as the Internet).
POS systems represent a very expensive investment for retailers. Retailers choose their POS provider after a lengthy Request for Proposal (RFP) process, and once the investment is made, they upgrade it only infrequently.
Extending the functionality of POS systems has always been a challenge but the recent popularity of coupons and the proliferation of mobile phones have put tremendous pressure on retailers to look at ways at supporting these functionalities as quickly as possible. Clearly, it is always possible to redesign and develop the POS software so that it supports issuance and redemption of coupons, and integrate with mobile channels, but this option is costly and time consuming.
FIG. 1 shows a typical POS configuration for a point-of sale system 1 comprising a POS terminal 3, a receipt printer 5, a barcode scanner 7, a data entry device 9 for the entry of PIN codes (the “Pin Pad”), back-office servers 11 and a payment processing server 13. The POS terminal, back-office servers 11 and payment processing server 13 are in communication with one another via a network 15 (which may be a local network, the Internet or a mixture of both).
The POS terminal 3 comprises a point of sale application software module 17, which is in communication with a product database 19, and a payment application software module 21.
The point of sale application software module 17 and payment application software module 21 are each in communication with the receipt printer 5 and scanner 7 and with the back-office servers 11 and payment processing server 13 via the network 15.
The point of sale application software module 17 is responsible for recording items to be sold one by one, calculating the total balance, triggering any pre-configured promotions, and then accepting multiple payment methods. Typically, items are input in using the scanner 7. Items having barcodes printed on external packaging will be placed in front of the scanner 7 which then scans the barcode and passes the barcode as input to the POS software module 17. The POS software module 17 will then query the local database 19 to retrieve the price of the item which may be displayed on a screen (not shown in FIG. 1).
Once all items are scanned, the cashier asks the customer to confirm their preferred payment type to use, and if the user chooses to pay by card, the POS software module 17 connects to the payment application software module 21.
The payment application software module 21 drives an external device 9 to get the credit card details and optionally the PIN associated with the card. In cases where a PIN code is not required, the payment application software module may interface with a magnetic strip reader (which may be integrated with the device 9) which reads the card details when the user or cashier swipes the card through the strip reader.
Once the transaction is paid for, the POS application software module 17 formats details of the transaction and sends them to the receipt printer 5. In many cases, two or more receipts are printed: one for the customer, and one for the retailer. It is noted that the retailer copy of the receipt can potentially contain more information than the customer one (for e.g. full card details, while the customer receipt contains only the last 4 digits of the card used).
The payment application software module 21 is responsible for authenticating the card, verifying the PIN, and authorising the card for payment. This is done by accessing the payment processor 13 over the network connection 15. The payment processor 13 may be either hosted inside or outside the premises of the retailer, and in that case it is hosted outside the retailer's premises, the network path from the payment application software module 21 to the payment processor 13 may involve leaving the retailer's local computer network and using the Internet or other communications network (e.g. dedicated communications network or a mobile telecommunications network). The network 15 is also used by the POS application software module 17 to send transaction details to the back-office servers 11.
The POS application software module 17 typically runs on a commodity operating system (e.g. Microsoft Windows or Linux). Each of the devices external to the POS terminal 3 is connected to the machine using standard connectors: Serial, Parallel, USB, or Ethernet ports. To simplify the interoperability between POS software and payment software vendors and external devices vendors, a consortium of companies led by Microsoft, NCR, Epson, and Fujitsu-ICL standardised the interface between each device. These standards are typically implemented in Java or COM technologies, and known under the name of JAVAPOS or OPOS.
It is noted that OPOS is an implementation of an interoperability standard for a Windows® operating system using Component Object Model (COM) technology. OPOS defines a set of control objects that define the interface of each device, and a set of service objects that implement the interface above, in a set of libraries called service objects. Typically, the service object is provided by the hardware provider (e.g. Epson for the printers).
JAVAPOS is the implementation of the standard in JAVA language. It uses the same architecture as OPOS, with a set of JAVA classes defining the interface of the API, and another set of JAVA classes defining the implementation of these interfaces, called service objects. Typically, the manufactures provides the implementation for these service objects in JAVA.
FIG. 2 shows a typical layout of the component of OPOS used to interface between a physical device 23 (e.g. the printer 5 or scanner 7 of FIG. 1) and the POS application software module 17. The POS application software module 17 is arranged to access the physical device 23 using a standard OPOS application programming interface (API) 30. Communication between the POS application software module 17 and the physical hardware device 23 is handled by an OPOS device 32 (which is actually a software stack within the POS terminal 3).
The OPOS device comprises an OPOS device control module 34 which provides the interface for the POS application software module 17 and an OPOS device service module 36 which provides communication to the device 23.
The OPOS Device Service module 36 implements the details of the physical device 23 and is typically provided by the hardware vendor. For example, to print receipt data, the POS application software module 17 may call the following method:
PrintNormal(Integer Station, String DataToBePrinted):                Prints the data specified in “DataToBePrinted” to the station specified in parameter “Station”. This is guaranteed to work regardless of the underlying printer attached to the POS terminal 3.        
Similar APIs exist for the scanner 7 as well. For example, regardless of the scanner attached to the POS terminal 3, the scanner property called “ScanData” always holds the scanned data. The POS application software module 17 upon receiving a read event from the scanner, can read this data, and it is guaranteed to hold the barcode of the item scanned.
An arrangement mirroring that of FIG. 2 may also be used to describe a JAVAPOS system for interfacing a POS software module with a hardware device.
To access the stream of data sent by the POS application software module 17 requires a change in the application so that appropriate code can be added in order to access the data.
It is noted that retailers are looking for ways to understand their customers, to reach them through a multitude of channels, to leverage mobile phones as another channel to engage with their customers and to collect information about the experience of customers in their stores. Typically, any of these actions would require major changes to be made to POS software and hardware.
For example to be able to collect information about customers, retailers have been using loyalty cards to build profiles of customers. While popular, loyalty cards are very expensive to manage. It costs more than £6 million to just manage the IT infrastructure required for loyalty cards. Offers associated with loyalty cards often still have to be sent using postal services, which is not only costly, but needs to be carefully planned ahead of time: retailers need to know what offers to give, in what quantity. Furthermore, if an offer is not performing as expected, there is no way to correct-course during the campaign.
To reach out to customers with offers in real-time, a retailer may opt to use a second printer to print coupons at the point of sale till. However, retailers who implement this solution are required to operate a loyalty card scheme, a set of colour printers and targeting software which is very costly. A single printer of the type used by these retailers has a retail price of hundreds of pounds and, for larger environments with multiple point of sale terminals this solution is therefore very costly.
It can therefore be appreciated that modifying the standard point of sale environment is a significant undertaking requiring access to transaction data (which therefore requires the POS hardware and/or software to be modified), associating transaction data with a loyalty card, and having another piece of software print offers through a second printer.
It is therefore an object of the present invention to provide a mechanism for modifying/enhancing the functionality of a point of sale system without requiring the addition of new hardware and without requiring the modification of POS provider proprietary software modules.